La dette cryptographique : qu'est-ce que c'est, pourquoi elle s'accumule et comment la rembourser

La cryptographie est omniprésente, et c’est précisément pour cette raison qu’il est si facile de l’ignorer. Elle protège les données en transit, au repos et en cours d’utilisation. Elle authentifie les connexions, vérifie l’identité des utilisateurs et des machines, et garantit l’intégrité du code, des conteneurs et des mises à jour d’ software . Elle fonctionne discrètement en arrière-plan des protocoles Internet, du trafic réseau, des applications, des serveurs et de tous les appareils qui y sont connectés.

Et comme cela fonctionne tout simplement, on part du principe que c’est sécurisé. Loin des yeux, loin du cœur. L’absence de problèmes visibles est confondue avec une garantie : si un système fonctionne, la cryptographie sous-jacente doit bien fonctionner, n’est-ce pas ? Pas tout à fait. Lorsque la cryptographie échoue, elle ne déclenche que rarement un signal d’alerte sur un tableau de bord ou n’envoie qu’ rarement une alerte Slack. Elle échoue en silence, laissant les systèmes exposés bien avant que quiconque ne remonte la piste de la panne ou de la faille jusqu’à un certificat expiré ou un algorithme faible.

C'est justement ce silence qui pose problème. Année après année, une cryptographie non gérée et vieillissante s'accumule pour former un passif qui ne fait que maintenant apparaître dans les audits, les cadres réglementaires et les défaillances opérationnelles. Ce passif porte un nom : la dette cryptographique.

Qu'est-ce que la dette cryptographique ?

La dette cryptographique correspond à l'accumulation de composants cryptographiques inconnus, non gérés et obsolètes, qui s'accumulent au fil des années en raison de pratiques consistant à « configurer puis oublier ». Il s'agit du poids cumulé des clés, certificats, algorithmes, protocoles et bibliothèques qui ont été déployés une seule fois et n'ont jamais fait l'objet d'une gestion active ; plus on tarde à s'en occuper, plus il devient coûteux d'y remédier.

La cryptographie ne reste pas efficace d’elle-même. Elle vieillit. Les recherches en cours mettent au jour de nouvelles failles, les connaissances mathématiques progressent, les algorithmes s’améliorent et les ordinateurs deviennent plus rapides et plus puissants. Ce qui était considéré comme sûr au moment de son déploiement peut discrètement passer sous le seuil de sécurité acceptable. Des algorithmes tels que DES, MD5, SHA-1 et RSA-512, par exemple, sont obsolètes depuis longtemps et facilement exploitables, mais ils persistent dans les applications héritées, les micrologiciels et les serveurs web.

La dette cryptographique se forme parce que la plupart des équipes considèrent les composants cryptographiques comme un élément dont le fournisseur du système d’exploitation, de l’application ou de la plateforme se chargera via des mises à jour de routine. Sans gestion active, sans outils ni gouvernance venant s’ajouter à ces mises à jour, la cryptographie se dégrade naturellement. Une grande partie de l’infrastructure cryptographique actuelle a été conçue il y a plus de trente ans et peine à suivre le rythme des architectures informatiques modernes. Il en résulte une base vieillissante, largement méconnue, en grande partie invisible et susceptible de tomber en panne avec des conséquences importantes. La dette cryptographique est omniprésente et invisible. « C’est le problème qui se cache derrière tous les autres problèmes », telle est la description qu’en a donnée Chris Hickman, RSSI d’ Keyfactor, lors d’unepromenade dans le parc. En quoi la dette cryptographique diffère-t-elle de la dette technique ordinaire ?

Toutes les équipes d'ingénieurs connaissent la dette technique : ce raccourci que l'on prend pour livrer un produit immédiatement et le refactoriser plus tard. La dette cryptographique semble similaire à première vue, mais elle se comporte de manière très différente. La dette cryptographique est comparable à la dette technique, mais avec un compte à rebours.

Ces différences sont importantes car elles modifient la manière dont la dette doit être gérée. La dette technique classique résulte généralement d’une décision que vous avez prise et que vous pouvez annuler. La dette cryptographique n’implique souvent aucune mauvaise décision : l’algorithme était approprié au moment où il a été choisi, mais le modèle de menace a évolué au-delà de ses capacités. La dette classique est ressentie à chaque sprint par l’équipe responsable du code. La dette cryptographique est utilisée par tout le monde mais n’appartient à personne ; elle reste donc invisible jusqu’à ce qu’un problème survienne. Cela s’explique en partie par le fait que la cryptographie n’a pas su évoluer pour s’adapter aux nouvelles réalités techniques, tant sur le plan de l’ingénierie que de la gouvernance.

Le tableau ci-dessous met en évidence cette différence.

Dimension	Dette technique ordinaire	Dette cryptographique
Origine	Un raccourci que vous avez pris. Livrez maintenant, refactorisez plus tard.	Ce choix était le bon au moment où il a été fait ; mais le modèle de menace a évolué.
Comptabilité d'exercice	À peu près linéaire. Vous payez à chaque fois que vous modifiez le code.	Une fonction en escalier. Rien, rien, rien, puis une date de fin de prise en charge ou une rupture.
Visibilité	L'équipe responsable en ressent les effets à chaque sprint. Les répercussions se font sentir en aval.	Invisible. Les tests sont réussis, aucune dégradation n'est constatée. Le système cesse de fonctionner lorsque la sécurité s'affaiblit avec le temps. Nécessite une détection active.
Rayon d'explosion	Généralement confiné au module qui le possède.	Dépasse les limites de confiance. Impose des contraintes à chaque pair, appareil connecté et certificat délivré.
Qui fixe la date limite ?	C'est vrai. Ça se dégrade quand les priorités changent.	Le NIST, le CA/Browser Forum, les autorités de régulation, les adversaires. Ce n'est pas négociable, ce n'est pas votre date limite.
Rétroactivité	La refactorisation a réglé le problème. L'ancien code a disparu.	La dette de confidentialité ne peut être remboursée. Le trafic capté aujourd'hui reste capté.
« Terminé » signifie	Les tests sont réussis, la couture a disparu.	Ce point est contesté. Le modèle « crypto-agile » n'a pas été mis en œuvre ; le modèle hybride n'est pas achevé.
Risque	Coûts d'entretien plus élevés, baisse de la productivité.	Failles de sécurité, interruptions de service, perte de confiance.

Pourquoi la dette cryptographique s'accumule

La dette cryptographique ne reste pas immobile. Plusieurs forces la poussent vers un point de basculement, et elles s'accélèrent toutes simultanément.

• La pression en matière de conformité s'intensifie.
  Des référentiels tels que PCI DSS 4.0, NIS2 et DORA formalisent les bonnes pratiques en matière de cryptographie, et les exigences relatives à l'inventaire deviennent la norme. Les auditeurs posent des questions pointues et attendent des réponses claires. Sans visibilité, un audit se transforme en une course effrénée et coûteuse plutôt qu'en un simple rapport.
• La durée de vie des certificats ne cesse de diminuer.
  TLS /SSL La durée de vie des certificats est passée de 398 jours en 2020 à 200 jours aujourd’hui, et devrait atteindre seulement 47 jours d’ici 2029. Si l’on tient également compte de l’augmentation du nombre de certificats dont une entreprise a besoin, cela représente une multiplication par 10 à 12 de la charge de travail liée aux renouvellements. Pour une organisation ne disposant que de 2 000 certificats, cela représente au moins 43 renouvellements par jour. Un seul renouvellement manqué peut entraîner la panne d’un service critique.
• La chaîne logistique de l'software e ne cesse de se complexifier.
  Entre 70 % et 90 % de l'software est désormais constitué de code tiers, notamment des bibliothèques open-source , des SDK de fournisseurs et des API, et bon nombre de ces composants intègrent leurs propres fonctions cryptographiques. Lorsqu'une faille apparaît, les équipes qui ne disposent pas d'un inventaire consacrent leur temps à rechercher le problème au lieu de le corriger.
• La transition vers l'ère post-quantique réduit la marge de manœuvre.
  Les nouvelles normes de cryptographie post-quantique (PQC), les calendriers de suppression progressive de la cryptographie classique et la menace immédiate que représentent les attaques de type «Harvest Now, Decrypt Later »(collecte immédiate, décryptageultérieur) font que la marge de manœuvre pour une migration progressive se réduit. Les experts s'attendent à ce que des ordinateurs quantiques capables de contourner la cryptographie à clé publique voient le jour d'ici environ 5 à 15 ans.

Ces forces ne constituent pas le cœur du problème. Elles ne sont que le catalyseur qui oblige les organisations à faire face à des décennies de dettes accumulées.

Où se cache la dette cryptographique

La cryptographie est présente dans bien plus d'endroits que ne le pensent la plupart des équipes. Un PC standard est livré avec plus de 500 éléments cryptographiques intégrés dans le micrologiciel, les systèmes d'exploitation et les applications. Multipliez ce chiffre par l'ensemble du parc informatique d'une entreprise, et l'ampleur de cette dette cachée apparaît clairement. Elle est complexe, fragmentée et souvent invisible, et s'accumule à plusieurs niveaux.

• Systèmes centraux :clés et certificats enfouis dans des magasins de clés non gérés, des fichiers de configuration et des services au niveau du système au sein des systèmes d'exploitation, des bases de données et des serveurs d'applications. Lorsqu'ils ne sont pas documentés, ils provoquent des pannes et des échecs d'audit.
• Terminaux :des centaines d'éléments par terminal au niveau du micrologiciel, des systèmes d'exploitation et des applications. Les outils de protection des terminaux détectent souvent ces éléments, mais il est rare qu'ils les répertorient ou les gèrent.
• Infrastructure réseau :TLS, SSH et IPSec assurent la sécurité des communications, mais des suites de chiffrement faibles, des certificats périmés et des erreurs de configuration perturbent régulièrement les services et exposent les données.
• Environnements cloud :les servicesPKI, KMS et HSM sont dispersés entre plusieurs fournisseurs et comptes, ce qui complique leur supervision.
• Environnements CI/CD :les clés, les bibliothèques, les algorithmes et les racines de confiance sont dispersés entre le code source, les binaires, les postes de travail des développeurs et les outils de pipeline, ce qui engendre des risques liés à la chaîne d'approvisionnement et retarde les mises en production.
• Dépendances tierces et « open-source » :risque cryptographique hérité qui n'est pas répertorié en l'absence d'une nomenclature cryptographique (CBOM).
• Systèmes de sécurité :les HSM, les KMS, les « PKI » et les outils de gestion du cycle de vie des certificats destinés à régir la cryptographie fonctionnent souvent en silos, ce qui accentue la fragmentation au lieu de la résoudre.

Les risques liés à la dette cryptographique

Les vulnérabilités cryptographiques ne sont pas de simples failles techniques isolées. Il s’agit de risques systémiques qui affectent la disponibilité, la conformité et la confiance, ce qui explique pourquoi les défaillances cryptographiques figurent parmi le Top 10 de l’OWASP. L’exposition s’étend bien au-delà des systèmes internes : 91 % des RSSI signalent une augmentation des incidents de cybersécurité liés à des tiers, mais seuls 3 % d’entre eux ont une visibilité sur leurs chaînes d’approvisionnement en « software s ». Les catégories concrètes de vulnérabilités sont les suivantes.

• Clés codées en dur, réutilisées et exposées :les clés de signature de code, les clés SSH et les jetons API intégrés dans le code source et les fichiers de configuration font l'objet de fuites via les dépôts publics, les audits et la rétro-ingénierie. Les fuites de secrets dans les dépôts « open-source » ont augmenté de 12 % d'une année sur l'autre, et les clés SSH privées ainsi que les clés de chiffrement représentaient plus de 40 % de ces fuites.
• Protocoles non chiffrés et obsolètes :Telnet, LDAP, SMTP et SNMPv2 continuent de transmettre des données en clair, et des erreurs de configuration laissent souvent des versions non chiffrées actives. Une étude réalisée en 2023 portant sur plus de 200 To de trafic réseau a révélé que 61 % de ce trafic était entièrement non chiffré et que jusqu’à 80 % présentait une faille exploitable dans son chiffrement.
• Algorithmes et suites de chiffrement obsolètes :des algorithmes tels que DES, MD5, SHA-1 et RSA-512 sont obsolètes depuis longtemps et facilement exploitables, mais ils persistent dans les systèmes hérités et de nombreuses organisations continuent de s'y fier. Même les systèmes prenant en charge un chiffrement fort recourent parfois à des protocoles et des suites de chiffrement faibles, ce qui les expose à des attaques par rétrogradation.
• Risques liés aux certificats :les certificats expirés, auto-signés et à longue durée de validité constituent l'une des principales causes de pannes, qui peuvent coûter entre 5 600 et 9 000 dollars par minute, le temps que les équipes s'empressent de les réémettre et de les remplacer. Nous abordons en détail la gestion des certificats dans notreguide dédié.
• Cryptographie non conforme et vulnérable aux attaques quantiques :une cryptographie personnalisée non documentée, reposant sur des bibliothèques défaillantes, peut passer inaperçue pendant des années jusqu’à ce qu’un audit la mette au jour, tandis que des algorithmes largement utilisés, tels que RSA et ECDSA, restent exposés à de futures attaques quantiques.

Considérés sous le bon angle, il s'agit là de risques métier, et pas seulement de risques techniques. Uninventaire cryptographiquealimente directement le système de gestion des risques d'entreprise (ERM), dans lequel les défaillances cryptographiques se traduisent par des risques opérationnels, de réputation et financiers, notamment des répercussions sur le bilan, des amendes réglementaires et une résilience des services compromise.

La cryptographie post-quantique (PQC) et l'horloge quantique

L'informatique quantique représente une menace fondamentale pour la cryptographiequi assure la sécurité de l'Internet moderne. En 1994, l'algorithme de Shor a démontré qu'un ordinateur quantique suffisamment puissant pourrait résoudre efficacement les problèmes de factorisation des grands nombres et de logarithme discret qui sont à la base de la cryptographie asymétrique actuelle. On s'attend généralement à ce qu'un ordinateur quantique capable de contourner la cryptographie à clé publique voie le jour d'ici 5 à 15 ans ; c'est pourquoi le secteur s'oriente désormais vers la migration de son infrastructure cryptographique vers des normes résistantes à l'informatique quantique.

Cette migration est difficile et délicate. Elle touche toutes les unités opérationnelles et l’ensemble de la chaîne de valeur, nécessite des ressources considérables et peut prendre une décennie, voire plus, de planification et de mise en œuvre. Certains systèmes existants pourraient ne jamais réussir à effectuer cette transition sans heurts. Négliger la « dette cryptographique » complique encore davantage la tâche : chaque clé inconnue, chaque algorithme non documenté et chaque certificat non géré ajoute des obstacles à une migration vers une cryptographie résistante à l’informatique quantique, déjà complexe en soi, retardant ainsi la mise en place d’une protection effective contre des adversaires dotés de capacités quantiques.

La menace ne se limite pas à l’avenir. Dans le cadre d’attaques de type « harvest now, decrypt later » (également appelées « store-now-decrypt-later »), les attaquants capturent aujourd’hui des données chiffrées et les stockent pour les déchiffrer une fois que les ordinateurs quantiques auront atteint leur maturité. Les données dont la durée de confidentialité est longue sont donc déjà menacées dès à présent. Si vous souhaitez approfondir le sujet, les articles explicatifs d’ Keyfactorsur les attaques « harvest now, decrypt later », la cryptographie post-quantique et les étapes clés vers une cryptographie résistante à l’informatique quantique constituent des points de départ utiles.

Inventaire cryptographique : la base du remboursement de la dette

On ne peut pas gérer ce qu’on ne voit pas, ni sécuriser ce qu’on ne trouve pas. Un inventaire cryptographique constitue la pierre angulaire d’une approche de votre parc cryptographique fondée sur les risques. Il s’agit d’un registre dynamique et exhaustif de tous les actifs cryptographiques présents dans l’ensemble de votre infrastructure numérique, qui apporte des réponses aux questions essentielles : de quoi disposons-nous, où se trouvent ces actifs, quelle est leur efficacité et par quoi faut-il commencer pour y remédier ?

Un bon inventaire recense les clés, les certificats, les secrets, les algorithmes, les magasins de clés, les chiffrements, les protocoles et les bibliothèques, ainsi que la manière dont chacun d'entre eux est configuré et utilisé dans la pratique. C'est précisément cet aspect qui distingue un inventaire complet d'un CBOM.

CBOM par rapport à l'inventaire cryptographique opérationnel

Une liste des composants cryptographiques (CBOM) répertorie les capacités cryptographiques intégrées à une application, telles que les algorithmes pris en charge (AES-256, RSA-2048, etc.), les bibliothèques (OpenSSL, Bouncy Castle, etc.) et les types de clés. Elle peut être générée à partir du code source et offre un aperçu rapide de l’architecture cryptographique d’une version d’ software . Ce qu’elle ne peut pas vous indiquer, c’est la manière dont cette software est configurée dans votre environnement. Un CBOM peut indiquer qu’une application prend en charge à la fois SHA-1 et SHA-256, mais il ne révélera pas lequel vous avez effectivement activé.

Un inventaire cryptographique opérationnel apporte cette couche manquante : les certificats, clés, suites de chiffrement et configurations spécifiques réellement utilisés. Le CBOM s'apparente avant tout à un élément fondamental d'un inventaire opérationnel plus large, qui recense également la configuration, l'utilisation, les dépendances et les politiques au sein de systèmes hétérogènes.### Pourquoi est-il difficile d'en créer un ?

L'omniprésence même de la cryptographie fait de l'inventaire complet un projet exigeant. Les ressources se cachent dans des sources hétérogènes, réparties entre les systèmes hérités, les services cloud et les applications tierces compilées. Les dépendances vis-à-vis de tiers limitent la visibilité. Les outils traditionnels de gestion des vulnérabilités et des menaces n’ont jamais été conçus pour établir un inventaire cryptographique ; ils laissent donc des lacunes. Les environnements évoluent constamment, l’inventaire doit donc rester à jour. L’automatisation est essentielle pour atteindre une échelle suffisante, mais les outils automatisés présentent des angles morts, ce qui signifie qu’une validation par des experts reste nécessaire pour filtrer le bruit et confirmer ce qui est réellement utilisé.

Dix principes stratégiques

Le livre blanc intitulé « Cryptographic Inventory» propose dix principes destinés à orienter cette démarche :

1. obtenir le soutien de la direction,
2. évoluer grâce à l'automatisation,
3. optimiser l'intervention manuelle,
4. hiérarchiser les efforts,
5. saisir le contexte pour apporter une valeur ajoutée,
6. générer des informations exploitables,
7. tirer parti de l'IA pour étendre les capacités,
8. notamment la cryptographie des fournisseurs,
9. définir une source de référence fiable, et
10. élaborer une stratégie pour gérer les faux positifs.

Ensemble, ils transforment les premières découvertes en un programme structuré par ordre de priorité et axé sur les risques, plutôt qu’en un exercice sans fin de collecte de données.

À qui appartient-il ?

La cryptographie étant utilisée par tous mais n'appartenant à personne, la responsabilité doit être attribuée de manière délibérée. Dans la plupart des grandes organisations, cette responsabilité incombe au DSI (CIO) ou au RSSI (CISO), un cadre de haut niveau étant en dernier ressort responsable de la cryptographie et de l'inventaire cryptographique. La responsabilité au quotidien est généralement répartie entre les équipes DevSecOps, l’informatique, une équipe cryptographique dédiée et le service chargé de la conformité en matière de sécurité, selon un modèle RACI (responsable, redevable, consulté, informé), les experts en cryptographie jouant un rôle de conseil afin que les décisions ne soient jamais prises sans l’expertise appropriée.

Agilité cryptographique

L'agilité cryptographique désigne la capacité à passer rapidement et efficacement d'un algorithme, d'une bibliothèque, d'une clé, d'un jeton, d'un certificat ou d'un protocole à un autre, sans perturbation opérationnelle majeure. Elle doit être considérée comme une propriété fondamentale de toute infrastructure cryptographique moderne, car c'est elle qui permet de réduire la dette cryptographique de manière durable, plutôt que de devoir procéder à de multiples opérations de nettoyage ponctuelles.

Il est essentiel de noter que le besoin d’agilité n’est pas uniquement lié à la menace quantique. La cryptographie ne doit pas être un élément de la pile technologique d’une entreprise que l’on configure une fois pour toutes. De nombreux facteurs imposent des mises à jour et des changements au fil du temps, notamment la dégradation de la sécurité, les exigences de compatibilité et l’évolution des obligations de conformité. L’agilité s’obtient en partie en abstraisant l’API des primitives cryptographiques, ce qui permet de remplacer les algorithmes à la demande, plutôt que de les intégrer de manière figée dans chaque application. Pour en savoir plus sur la manière d’y parvenir, consultez le guide d’ Keyfactorconsacré à l’agilité cryptographique et à la préparation à la migration post-quantique.

Modernisation cryptographique : une démarche reproductible, de la découverte à l'agilité cryptographique

La modernisationne se résume pas à une simple décision concernant la cryptographie post-quantique. Il s’agit d’un programme par étapes, et les organismes de régulation, notamment la CISA, la NSA et le NIST, indiquent clairement que les entreprises ne doivent pas se précipiter dans le déploiement de la cryptographie post-quantique. Le consensus est le suivant : « commencer par l’inventaire », puis procéder à l’évaluation des risques et mettre en place une architecture « crypto-agile ». Le modèle de maturité en matière de « crypto-agilité » du NIST lui-même le confirme : les organisations n’atteignent pas un niveau d’agilité reproductible tant que la détection des failles cryptographiques et leur correction ne sont pas automatisées et maintenues en continu. Un programme concret se déroule en quatre phases.

1. Recensement et inventaire cryptographiques.
   Mettez en place un inventaire cryptographique proactif lié aux systèmes critiques pour l'entreprise, en établissant une corrélation entre les actifs et les choix d'algorithmes, la taille des clés, les délais d'expiration, les chaînes de confiance et les modèles d'utilisation. Le résultat obtenu est une base de référence défendable et une carte thermique des risques, et pas simplement davantage de données.
2. Remédiation et renforcement de la sécurité basés sur les risques.
   Éliminez les dépendances fragiles en intégrant les certificats non gérés et les autorités de certification « fantômes » dans un processus de gestion du cycle de vie, supprimez les algorithmes obsolètes, renforcez les tailles de clés insuffisantes, corrigez les configurations de protocoles non sécurisées et normalisez les processus d’émission et de signature. Renforcez les mesures de sécurité de base avant d’y ajouter la cryptographie post-quantique (PQC).
3. Automatisation et « crypto-agilité » à grande échelle.
   Transformez l'émission, le renouvellement, la rotation et la révocation en workflows orchestrés et régis par des politiques, intégrés aux plateformes cloud et DevOps. Ajoutez une surveillance continue de la posture de sécurité et des schémas de rotation minimisant les temps d'arrêt, afin que les changements cryptographiques deviennent une opération courante et sûre à répéter.
4. Gouvernance pour une adoption durable de la PQC.
   S'appuyer sur les organismes de normalisation (calendriers du NIST, de l'IETF, de l'ETSI, de l'ISO/IEC et de la CNSA 2.0) comme boussole, traduire leurs recommandations en politiques applicables et en modèles de conception, et mettre en œuvre une gouvernance suivant un rythme aligné sur les indicateurs opérationnels et les rapports destinés à la direction.

En résumé, la visibilité établit la vérité, l'automatisation élimine la fragilité et la « crypto-agilité » rend le progrès reproductible.

Comment Keyfactor vous aider

Le remboursement de la « dette cryptographique » consiste en fin de compte à faire passer la cryptographie du statut de passif caché à celui de capacité réglementée, et c'est précisément l'objectif d'Keyfactor .

• Assurer la visibilité.
  Keyfactor AgileSecassure la visibilité cryptographique et l'inventaire dans les centres de données, les comptes cloud, les terminaux, les environnements OT/IoT , ainsi que les environnements applicatifs, y compris les workflows de signature qui échappent souvent à la visibilité traditionnelle d'PKI .
• Centraliser la gestion des certificats.
   Keyfactor Command intègre les certificats non gérés et les autorités de certification parallèles dans une gestion automatisée du cycle de vie, de sorte que l'émission, le renouvellement, la rotation et l'application des politiques deviennent des opérations régies par des règles plutôt que des interventions d'urgence.
• Standardiser l'émission et la signature.
   Keyfactor EJBCA fournit des solutions de gestion des certificats ( PKI) de niveau entreprise et prêtes pour l'ère quantique, ainsi que des services de gestion des certificats ( Keyfactor )SignServer . Ces solutions centralisent la signature du code, des micrologiciels et des documents, remplaçant ainsi les implémentations locales sur mesure par des services partagés et auditable.
• Mettre en place une couche de contrôle favorisant la flexibilité cryptographique.
  Ensemble, ces composants constituent la couche de contrôle permanente qui permet de mettre en œuvre la modernisation au quotidien. Grâce au partenariat entre l’ Keyfactor et IBM Consulting, cette couche de contrôle s’accompagne d’une stratégie résistante à l’informatique quantique et d’une mise en œuvre à l’échelle de l’entreprise, permettant ainsi de traduire les décisions relatives à la feuille de route en actions séquencées et justifiables