ECDSA vs RSA : Signatures 9,5x Plus Rapides [2026]

En 2012, Cloudflare ne comptait que 50 certificats ECDSA parmi 13 millions de certificats TLS observés sur Internet, un rapport de force qui semblait figé pour longtemps. Au premier trimestre 2026, la situation a radicalement changé : ECDSA représente 42,9 % de tous les certificats émis dans le monde, contre 57,1 % pour RSA, selon une analyse de 10,9 milliards de certificats publiée par TechnologyChecker.io. Les données préliminaires du deuxième trimestre 2026 suggèrent même une quasi-parité entre les deux algorithmes, une bascule que personne n’anticipait aussi rapide dix ans plus tôt.

Ce basculement pose une question concrète à tout développeur, administrateur système ou RSSI en France et en Europe : faut-il encore déployer du RSA en 2026, ou ECDSA est-il devenu le choix par défaut pour un nouveau projet ? Le débat ECDSA vs RSA n’est plus purement théorique, il détermine directement la vitesse de chargement d’un site, la facture de bande passante et la compatibilité avec le parc client. Cet article compare les deux algorithmes de signature les plus utilisés sur Internet à partir de benchmarks publiés (Cloudflare, SSL.com, SEGGER), de données d’adoption réelles et des recommandations de l’ANSSI et du NIST pour 2026. Vous trouverez aussi un guide de migration et un verdict chiffré à la fin.

Qu’est-ce que RSA ? Le vétéran de la cryptographie à clé publique

RSA (Rivest-Shamir-Adleman) date de 1977 et reste, près de cinquante ans plus tard, l’algorithme de signature et de chiffrement asymétrique le plus déployé au monde. Sa sécurité repose sur la difficulté à factoriser le produit de deux grands nombres premiers. Un attaquant qui veut casser une clé RSA doit résoudre un problème de factorisation qu’aucun ordinateur classique ne sait traiter en un temps raisonnable pour des clés de 2048 bits ou plus.

Concrètement, RSA sert à chiffrer des données et à signer des documents ou des certificats. Un certificat TLS RSA-2048 embarque une clé publique de 256 octets. Sa génération demande de chercher deux grands nombres premiers par tâtonnement probabiliste, une opération intrinsèquement plus lourde que le simple calcul algébrique utilisé par ECDSA, et qui ralentit encore quand la taille de clé grimpe à 3072 ou 4096 bits. RSA reste malgré tout la norme dans les environnements où la compatibilité prime : anciens navigateurs, équipements réseau hérités, cartes à puce, systèmes bancaires legacy.

Sa faiblesse tient moins à sa sécurité intrinsèque qu’à son poids. Plus le niveau de sécurité recherché augmente, plus les clés RSA grossissent vite. Passer de 112 à 128 bits de sécurité équivalente fait grimper la clé RSA de 2048 à 3072 bits, alors qu’une courbe elliptique grossit beaucoup plus lentement pour le même gain.

Qu’est-ce qu’ECDSA ? La cryptographie à courbes elliptiques

ECDSA (Elliptic Curve Digital Signature Algorithm) applique le principe de la signature numérique à la géométrie des courbes elliptiques plutôt qu’à la factorisation. La norme s’est généralisée dans les années 2000, bien après RSA, et sa sécurité repose sur la difficulté du problème du logarithme discret sur une courbe elliptique. Ce problème résiste pour l’instant mieux à la cryptanalyse que la factorisation : d’après Cloudflare, la résolution du logarithme discret elliptique n’a connu aucune avancée majeure depuis son introduction indépendante par Koblitz et Miller en 1985.

L’intérêt pratique d’ECDSA tient à la taille des clés. Une clé ECDSA P-256 offre un niveau de sécurité comparable à une clé RSA de plusieurs milliers de bits, tout en occupant seulement 64 octets contre 256 pour RSA-2048. Une signature ECDSA P-256 pèse environ 64 à 72 octets une fois encodée en DER, contre 256 octets pour une signature RSA-2048.

Ce gain de poids se traduit directement en vitesse de calcul. Cloudflare a mesuré 9 516,8 signatures par seconde avec une clé ECDSA P-256, contre 1 001,8 signatures par seconde pour RSA-2048 sur le même matériel, soit un facteur supérieur à 9,5x en faveur d’ECDSA. Les courbes les plus courantes restent P-256, P-384 et P-521, nommées d’après la taille en bits du nombre premier qui définit la courbe. En dehors du TLS, ECDSA équipe aussi l’écosystème des cryptomonnaies : Bitcoin et Ethereum signent leurs transactions avec ECDSA sur la courbe secp256k1, un choix qui remonte à la création de Bitcoin en 2009 et qui explique en partie la popularité actuelle de cette famille d’algorithmes en dehors du seul monde du certificat TLS.

ECDSA vs RSA : le tableau comparatif complet

Le tableau ci-dessous résume les différences entre RSA et ECDSA sur treize critères techniques, des fondations mathématiques à la résistance face à l’ordinateur quantique. Les chiffres de vitesse proviennent de mesures publiées par Cloudflare et par SEGGER, spécialiste des systèmes embarqués, détaillées plus loin dans la section consacrée aux benchmarks.

Critère	RSA	ECDSA
Standardisation	1977, norme PKCS#1	Généralisée dans les années 2000 (FIPS 186-5)
Fondement mathématique	Factorisation de grands nombres premiers	Logarithme discret sur courbe elliptique
Taille de clé pour ~112 bits de sécurité	2048 bits	224 à 255 bits
Taille de clé pour ~128 bits de sécurité	3072 bits	256 bits
Taille de clé publique	256 octets (2048 bits)	64 octets (P-256)
Taille de signature (DER)	256 octets (RSA-2048)	64 à 72 octets (P-256)
Génération de clé	Lente, recherche probabiliste de nombres premiers	Rapide, simple calcul sur la courbe
Signatures par seconde (Cloudflare, matériel serveur)	1 001,8 (RSA-2048)	9 516,8 (P-256)
Vérification embarquée (SEGGER, Cortex-M7, niveau 128 bits)	15,89 ms (RSA-3072)	78,70 ms (P-256)
Compatibilité clients	Quasi universelle, y compris systèmes anciens	Tous les clients modernes
Sensibilité aux erreurs d’implémentation	Faible si le padding est correct (OAEP/PSS)	Élevée, dépend de la qualité du nonce
Usages typiques	TLS legacy, cartes à puce, signature de code	TLS moderne, SSH, JWT (ES256), blockchain
Résistance à l’ordinateur quantique	Cassable par l’algorithme de Shor	Cassable par l’algorithme de Shor

Performances : ce que montrent réellement les benchmarks

Vitesse de signature sur un serveur classique

Sur un serveur web standard, l’avantage d’ECDSA en vitesse de signature est net. Le chiffre le plus souvent cité, celui de Cloudflare, montre 9 516,8 signatures par seconde en ECDSA P-256 contre 1 001,8 en RSA-2048 sur le même matériel, soit 9,5 fois plus. Cet écart compte pour un site à fort trafic qui doit établir des milliers de connexions TLS par seconde, car chaque poignée de main consomme un cycle de signature côté serveur. Un CDN ou un répartiteur de charge qui traite des pics de connexions ressent directement cette différence en charge CPU.

Le cas particulier des systèmes embarqués

Sur du matériel contraint, le résultat peut s’inverser, et c’est là que les benchmarks génériques trompent le plus. Le laboratoire de SEGGER, spécialiste des systèmes embarqués, a mesuré le temps de vérification de signature sur un microcontrôleur Cortex-M7 cadencé à 200 MHz, à cinq niveaux de sécurité croissants. Au niveau 128 bits, la vérification RSA-3072 prend 15,89 ms contre 78,70 ms pour ECDSA P-256, RSA restant nettement plus rapide à ce palier. Mais la courbe s’inverse aux niveaux de sécurité élevés : à 256 bits, RSA-16384 grimpe à 333,19 ms de vérification, contre seulement 145,68 ms pour ECDSA P-521. Autrement dit, plus le niveau de sécurité visé est élevé, plus ECDSA finit par devenir compétitif même en vérification, à l’inverse de ce qu’on observe aux niveaux de sécurité courants.

Le même banc d’essai SEGGER montre que RSA reste plus économe en mémoire sur ces microcontrôleurs, avec 6 Kio de ROM et 3,0 Kio de RAM utilisés contre 10 Kio de ROM et 3,2 Kio de RAM pour ECDSA. Sur un objet connecté à ressources limitées, ce delta de mémoire flash peut peser autant que la vitesse brute dans le choix final. C’est un rappel utile : le choix entre RSA et ECDSA dépend du profil matériel visé et du niveau de sécurité cible, pas d’une règle universelle valable pour tous les contextes.

Sécurité et équivalence des tailles de clés

Comparer RSA et ECDSA à nombre de bits égal n’a pas de sens, car les deux algorithmes ne mesurent pas la sécurité de la même façon. Le tableau ci-dessous reprend les équivalences de sécurité standard utilisées par l’industrie, du niveau 80 bits, aujourd’hui jugé insuffisant, au niveau 256 bits, réservé aux données les plus sensibles.

Niveau de sécurité	Taille de clé RSA requise	Taille de clé ECC requise
80 bits	1024 bits	160 à 223 bits
112 bits	2048 bits	224 à 255 bits
128 bits	3072 bits	256 à 383 bits
192 bits	7680 bits	384 à 511 bits
256 bits	15360 bits	512 bits et plus

Cette progression explique pourquoi RSA devient vite impraticable aux niveaux de sécurité élevés. Passer de 128 à 256 bits de sécurité multiplie la clé RSA par cinq (de 3072 à 15360 bits), alors que la clé ECC correspondante double à peine. Cloudflare cite d’ailleurs une équivalence légèrement différente, issue des recommandations ECRYPT II : une clé elliptique de 256 bits y est jugée aussi robuste qu’une clé asymétrique de 3248 bits. Les deux référentiels ne s’accordent pas au bit près, ce qui est normal, mais ils pointent dans la même direction : à sécurité égale, ECDSA reste nettement plus compact que RSA.

L’erreur d’implémentation qui a coûté sa clé maîtresse à Sony

La sécurité théorique d’ECDSA ne protège rien si l’implémentation triche sur un seul paramètre : le nonce, ce nombre aléatoire à usage unique généré à chaque signature. En décembre 2010, au 27e Chaos Communication Congress, le groupe fail0verflow a montré que Sony réutilisait exactement le même nonce pour signer tous les logiciels de la PlayStation 3, au lieu d’en tirer un nouveau à chaque fois, selon un compte-rendu publié par SiliconANGLE. Deux signatures ECDSA produites avec le même nonce suffisent, par un simple calcul algébrique, à retrouver la clé privée complète.

Le chercheur George Hotz a ensuite publié la clé racine récupérée par ce biais. N’importe qui pouvait alors signer un exécutable que la console accepterait comme authentique, jeu piraté ou application Linux non autorisée compris. Pire pour Sony, cette clé était gravée dans la racine de confiance matérielle de la console : impossible de la faire tourner discrètement comme on renouvelle un certificat TLS. Cet épisode reste, quinze ans plus tard, l’exemple de référence enseigné pour illustrer pourquoi la qualité du générateur de nombres aléatoires compte autant que le choix de l’algorithme lui-même. RSA n’est pas à l’abri de tout, mais son schéma de signature ne dépend pas d’un nonce frais à chaque opération, ce qui élimine cette classe entière d’erreurs.

Qui utilise RSA et qui utilise ECDSA en 2026 ?

TechnologyChecker.io a analysé 10,9 milliards de certificats TLS/SSL émis au premier trimestre 2026. Résultat : RSA conserve une majorité, avec 57,1 % des émissions, contre 42,9 % pour ECDSA. Un an plus tôt, ECDSA ne représentait qu’environ 26,5 % des certificats émis sur une période comparable, ce qui traduit une progression de plus de vingt points de pourcentage en douze mois. Les données préliminaires du deuxième trimestre 2026 indiquent qu’ECDSA a continué de grignoter du terrain, jusqu’à approcher la parité avec RSA sur certaines fenêtres mensuelles.

Ce basculement ne doit rien au hasard. Il suit la généralisation des certificats à courte durée de vie, portée par Let’s Encrypt depuis 2015 et désormais imposée à tout le secteur par le CA/Browser Forum, où la rapidité de génération d’ECDSA pèse chaque jour un peu plus lourd dans la décision technique. Le marché des autorités de certification reste par ailleurs très concentré. Voici la répartition par émetteur observée sur la période, toujours selon TechnologyChecker.io.

Autorité de certification	Part de marché
Let’s Encrypt (ISRG)	56,7 %
Google Trust Services	13,4 %
Sectigo / ZeroSSL	11,8 %
Amazon Trust Services	6,5 %
Microsoft Corporation	1,3 %

Let’s Encrypt émet à lui seul plus de la moitié des certificats mondiaux et supporte RSA comme ECDSA sans surcoût, ce qui en fait un bon indicateur des préférences réelles des administrateurs système plutôt que des seules stratégies marketing des autorités payantes.

Six exemples concrets d’adoption dans le monde réel

Cloudflare a été l’un des premiers grands acteurs à pousser ECDSA à grande échelle sur son réseau de périphérie, dès une époque où moins de 50 certificats ECDSA existaient parmi 13 millions de certificats scannés en 2012.
Let’s Encrypt délivre 56,7 % de tous les certificats TLS mondiaux et permet de choisir librement entre chaîne RSA et chaîne ECDSA, sans différence de prix puisque le service est gratuit.
L’écosystème OpenSSH a désactivé l’algorithme de signature ssh-rsa par défaut depuis la version 8.8, au profit des variantes RSA-SHA2 et surtout d’Ed25519, devenu le type de clé par défaut depuis OpenSSH 9.5. ECDSA reste disponible via la RFC 5656 mais n’est plus mis en avant par le projet.
Le NIST et les systèmes fédéraux américains planifient, via le rapport NIST IR 8547, une dépréciation de RSA, ECDSA, ECDH et Diffie-Hellman classique à partir de 2030, puis leur interdiction complète en 2035, au profit d’algorithmes post-quantiques comme ML-DSA.
L’ANSSI et l’administration française recommandent depuis mars 2026, dans son guide ANSSI-PG-083, une hybridation entre cryptographie classique et post-quantique pour toute donnée dont la confidentialité doit tenir plus de dix ans, avec un déploiement progressif dès 2025 pour les entités les plus sensibles.
Le marché mondial des autorités de certification illustre la cohabitation actuelle : les cinq plus gros émetteurs (Let’s Encrypt, Google Trust Services, Sectigo/ZeroSSL, Amazon Trust Services, Microsoft) proposent tous RSA et ECDSA en parallèle, sans forcer un choix unique côté client, et laissent la décision aux équipes techniques plutôt qu’à un standard imposé.

Combien coûte un certificat RSA ou un certificat ECDSA ?

C’est sans doute la plus mauvaise raison de choisir un algorithme plutôt qu’un autre : le prix. Chez SSL.com, tous les certificats listent RSA et ECC comme deux options interchangeables, au même tarif. Voici la grille officielle publiée par ce fournisseur en 2026.

Produit	Validation	Domaines	Prix indicatif	Algorithme
Basic	DV	1	à partir de 36,75 $/an	RSA ou ECC au choix
High Assurance	OV	1	à partir de 48,40 $/an	RSA ou ECC au choix
Premium	OV	3	à partir de 74,25 $/an	RSA ou ECC au choix
Multi-domaines (UCC/SAN)	OV	jusqu’à 500	à partir de 141,60 $/an	RSA ou ECC au choix
Wildcard	OV	1 + sous-domaines	à partir de 224,25 $/an	RSA ou ECC au choix
Enterprise EV	EV	1	à partir de 239,50 $/an	RSA ou ECC au choix
Let’s Encrypt	DV	illimité	Gratuit	RSA ou ECC au choix

Du côté des revendeurs européens, les gammes Sectigo observées début 2026 démarrent autour de 101 € par an et montent jusqu’à 229 € par an selon le niveau de validation, sans surcoût lié à l’algorithme non plus. Un autre changement pèsera bien plus sur vos coûts opérationnels que le choix RSA ou ECDSA : le CA/Browser Forum a ramené la durée de vie maximale d’un certificat à 200 jours en mars 2026, avec une trajectoire annoncée vers 47 jours d’ici 2029. Plus les certificats tournent vite, plus la rapidité de génération de clé d’ECDSA devient un critère opérationnel concret, en particulier pour l’automatisation via ACME, où des milliers de renouvellements peuvent désormais se produire chaque mois plutôt que chaque année.

La menace quantique change la donne pour RSA et ECDSA

RSA et ECDSA partagent une même vulnérabilité de fond : les deux tombent face à un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor. Le NIST a franchi une étape décisive le 13 août 2024 en publiant les normes finales FIPS 203, FIPS 204 et FIPS 205, qui standardisent respectivement ML-KEM (échange de clés), ML-DSA (signatures) et SLH-DSA (signatures basées sur le hachage), les trois familles d’algorithmes post-quantiques retenues pour remplacer RSA et ECDSA à terme.

Le calendrier de transition est déjà posé. Le rapport NIST IR 8547, publié en version provisoire le 12 novembre 2024, prévoit que RSA, ECDSA, ECDH, DSA et Diffie-Hellman classique soient dépréciés après 2030 puis totalement interdits en 2035 pour les systèmes fédéraux américains. Passé 2030, tout usage de ces algorithmes nécessitera une justification documentée du risque accepté. Une exception notable subsiste : les modes hybrides, qui combinent un algorithme post-quantique approuvé avec un algorithme classique comme RSA ou ECDSA, échappent à l’interdiction de 2035 et servent justement de pont pendant la transition.

Ce calendrier ne signifie pas qu’il faut abandonner RSA ou ECDSA du jour au lendemain en 2026. Il signifie qu’un nouveau projet à longue durée de vie devrait déjà prévoir une voie de migration, ou au minimum un mode hybride, plutôt que de miser uniquement sur la cryptographie classique pour la décennie à venir.

ANSSI, ENISA : la position de la France et de l’Europe

L’ANSSI a mis à jour ses règles et recommandations concernant le choix des mécanismes cryptographiques dans son guide ANSSI-PG-083, daté du 20 mars 2026. Pour RSA, l’agence fixe une taille de module minimale de 2048 bits pour tout usage ne devant pas dépasser l’année 2030, et relève cette exigence à 3072 bits minimum pour un usage prévu au-delà de 2030. Pour ECDSA, l’ANSSI valide les courbes à 256, 384 ou 521 bits, ce qui correspond aux familles P-256, P-384 et P-521 déjà largement déployées.

Sur le volet post-quantique, l’ANSSI recommande une hybridation entre cryptographie classique et post-quantique dès 2025 pour toute donnée dont la durée de vie dépasse dix ans, comme les archives d’État ou les dossiers médicaux. Elle considère la migration post-quantique comme une mesure de sécurité attendue pour les entités essentielles et importantes au sens de la directive NIS2, avec un horizon de mise en œuvre fixé entre 2027 et 2030. Cette trajectoire fait écho à un autre chantier suivi de près en France, la fin programmée des certificats RGS serveur qui pousse les administrations vers des certificats qualifiés eIDAS reconnus par l’ANSSI, sujet que nous avons déjà couvert en détail concernant la fin des certifications sans PQC dès 2027.

À l’échelle de l’Union européenne, l’ENISA pousse dans la même direction que l’ANSSI, avec une préférence marquée pour les schémas hybrides combinant un algorithme classique comme RSA ou ECDSA et un algorithme post-quantique. La Commission européenne, appuyée par l’ENISA, a lancé une feuille de route coordonnée entre États membres qui vise une sécurisation des systèmes les plus critiques d’ici fin 2030 et une transition complète vers la cryptographie post-quantique d’ici 2035, un calendrier qui recoupe presque exactement celui du NIST américain malgré des processus de décision séparés.

Ces recommandations placent la France et l’Europe dans une position prudente mais alignée sur le NIST américain. RSA et ECDSA restent autorisés aujourd’hui, à condition de respecter les tailles minimales, mais aucun des deux ne doit plus être considéré comme un choix définitif pour un système censé fonctionner encore en 2035.

Générer des clés RSA et ECDSA : exemples de code

Voici comment générer chaque type de clé avec OpenSSL, l’outil en ligne de commande le plus répandu pour ce genre de tâche.

# Générer une clé privée RSA-3072 et un certificat auto-signé
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa_key.pem
openssl req -new -x509 -key rsa_key.pem -out rsa_cert.pem -days 200

# Générer une clé privée ECDSA sur la courbe P-256 et un certificat auto-signé
openssl ecparam -name prime256v1 -genkey -noout -out ecdsa_key.pem
openssl req -new -x509 -key ecdsa_key.pem -out ecdsa_cert.pem -days 200

Sur la plupart des distributions Linux récentes, la génération de la clé ECDSA ci-dessus se termine quasi instantanément, alors que la clé RSA-3072 demande un temps nettement plus perceptible en ligne de commande, un écart cohérent avec la logique de recherche probabiliste de nombres premiers décrite plus haut. Pour vérifier quel algorithme protège déjà un certificat existant, la commande suivante affiche directement le type de clé publique utilisé.

# Identifier l'algorithme d'un certificat existant
openssl x509 -in certificat.pem -noout -text | grep "Public Key Algorithm"

Pour Node.js, nous avons détaillé la mise en œuvre côté application dans notre guide ECDSA et Ed25519 en 12 étapes, avec des exemples concrets de signature et de vérification en JavaScript.

Migrer de RSA vers ECDSA : le guide étape par étape

Une migration mal préparée casse plus de connexions qu’elle n’en sécurise, surtout si une partie du parc client repose encore sur des bibliothèques TLS anciennes. Voici la démarche à suivre pour basculer un service de RSA vers ECDSA sans interruption, du premier audit jusqu’au retrait définitif de l’ancien certificat.

Faites l’inventaire de tous les certificats RSA actifs (serveurs web, API internes, VPN, IoT) et notez leur date d’expiration.
Vérifiez la compatibilité de vos clients les plus anciens avec ECDSA. Un parc encore sous Windows XP ou Java 6 ne supporte pas correctement les courbes elliptiques modernes.
Générez une paire de clés ECDSA P-256 en environnement de test, comme montré dans les exemples de code ci-dessus, et faites-la tourner sur un sous-domaine de préproduction avant tout déploiement public.
Demandez un certificat ECDSA auprès de votre autorité de certification actuelle. Let’s Encrypt, Sectigo et la plupart des CA majeures le proposent au même tarif que RSA, souvent via une simple option dans la demande de signature de certificat (CSR).
Déployez les deux certificats en parallèle sur votre serveur, une configuration à double certificat RSA et ECDSA supportée nativement par Nginx, Apache et Cloudflare.
Configurez votre serveur pour servir ECDSA aux clients compatibles et basculer automatiquement vers RSA pour les anciens clients, via la négociation TLS standard.
Surveillez vos journaux TLS pendant deux à quatre semaines pour repérer les échecs de négociation liés à ECDSA.
Une fois le taux d’échec proche de zéro, laissez expirer naturellement le certificat RSA sans le renouveler.
Mettez à jour votre documentation interne et vos scripts d’automatisation ACME pour référencer ECDSA comme algorithme par défaut.
Si vos données doivent rester confidentielles au-delà de 2035, ajoutez dès maintenant une couche hybride post-quantique plutôt que d’attendre la prochaine migration.

Avantages et inconvénients de chaque algorithme

RSA : avantages et inconvénients

Compatibilité quasi universelle, y compris avec du matériel et des logiciels anciens.
Implémentation simple et bien comprise depuis près de cinquante ans, moins sensible aux erreurs de génération aléatoire que ECDSA.
Écosystème d’outils, de bibliothèques et de documentation le plus mature du marché.
Clés et signatures nettement plus lourdes à niveau de sécurité équivalent, ce qui alourdit chaque poignée de main TLS.
Génération de clé beaucoup plus lente, un problème grandissant avec des certificats dont la durée de vie maximale se réduit chaque année.

ECDSA : avantages et inconvénients

Clés et signatures beaucoup plus compactes, ce qui réduit la bande passante et accélère l’établissement de chaque connexion TLS.
Génération de clé quasi instantanée, idéale pour les certificats à courte durée de vie et l’automatisation via ACME.
Signature environ 9,5 fois plus rapide que RSA-2048 sur du matériel serveur classique, selon les mesures de Cloudflare.
Sécurité très sensible à la qualité du générateur de nombres aléatoires utilisé pour le nonce, comme l’a démontré l’incident Sony PS3.
Vérification parfois plus lente que RSA aux niveaux de sécurité courants, notamment sur certains microcontrôleurs contraints, selon les mesures SEGGER.
Adoption plus récente, ce qui laisse encore quelques poches d’incompatibilité avec du matériel réseau ou des clients très anciens.

Quel algorithme choisir selon votre cas d’usage ?

Site web public à fort trafic : ECDSA P-256, pour le gain de vitesse de signature et la réduction de bande passante sur chaque poignée de main TLS.
API qui valide surtout des jetons entrants : RSA peut rester pertinent, car sa vérification est plus rapide qu’ECDSA sur certains profils de charge.
Objets connectés ou microcontrôleurs contraints : testez les deux sur le matériel cible avant de trancher, les résultats SEGGER montrent que RSA peut l’emporter selon l’opération dominante et le niveau de sécurité visé.
Infrastructure publique française avec données sensibles de longue durée : suivez les recommandations ANSSI-PG-083 et ajoutez une hybridation post-quantique dès maintenant, en particulier pour les archives et dossiers médicaux.
Connexions SSH vers des serveurs : privilégiez Ed25519, désormais le type de clé par défaut d’OpenSSH depuis la version 9.5, plutôt qu’ECDSA ou RSA.
Compatibilité avec un parc client hétérogène ou ancien : gardez RSA en secours, en configuration à double certificat aux côtés d’ECDSA, le temps que le parc se renouvelle naturellement.
Signature de code ou de documents à très longue durée de validité : privilégiez RSA-3072 minimum dès aujourd’hui, ou anticipez directement un schéma hybride post-quantique si la signature doit rester vérifiable après 2035.

Le verdict : RSA ou ECDSA en 2026 ?

Les chiffres penchent clairement du côté d’ECDSA pour un nouveau déploiement TLS grand public en 2026. La vitesse de signature, 9,5x supérieure selon Cloudflare, la taille des clés et des certificats, jusqu’à quatre fois plus légers, et la gratuité du choix chez la quasi-totalité des autorités de certification jouent toutes en sa faveur. La progression du marché confirme cette tendance : ECDSA est passé d’environ 26,5 % à 42,9 % des émissions en un an, avec une trajectoire qui pointe vers la parité.

RSA garde cependant trois terrains où il reste défendable en 2026 : la compatibilité avec du matériel ancien qu’on ne peut pas mettre à jour, certains environnements embarqués où la vérification RSA bat ECDSA en vitesse aux niveaux de sécurité courants d’après SEGGER, et les organisations qui n’ont simplement pas encore d’urgence à migrer un système qui fonctionne. Aucun de ces trois cas ne justifie de démarrer un projet neuf sous RSA par défaut en 2026, ils justifient seulement de ne pas arracher RSA là où il rend encore service.

Dans tous les cas, ni RSA ni ECDSA ne doivent être vus comme un choix figé pour la décennie à venir. Le calendrier NIST IR 8547, dépréciation après 2030 et interdiction en 2035, et les recommandations ANSSI de mars 2026 poussent vers une hybridation post-quantique pour tout système censé durer au-delà de 2030. L’incident Sony rappelle en parallèle qu’un bon choix d’algorithme ne compense jamais une mauvaise implémentation : la qualité du générateur aléatoire compte souvent plus que le nombre de bits affiché sur la clé.

En résumé : choisissez ECDSA P-256 par défaut pour un nouveau projet web en 2026, gardez RSA en secours pour la compatibilité, et commencez dès maintenant à documenter votre trajectoire vers la cryptographie post-quantique si vos données doivent rester protégées après 2035.

Questions fréquentes

RSA est-il obsolète en 2026 ?

Non. RSA reste utilisé sur 57,1 % des certificats TLS au premier trimestre 2026 selon TechnologyChecker.io, et il reste considéré comme sûr par l’ANSSI et le NIST tant que la taille de clé respecte les minimums recommandés. Il n’est pas obsolète, mais il perd du terrain face à ECDSA et devra, comme ECDSA, céder la place à la cryptographie post-quantique d’ici 2030-2035 selon le calendrier NIST et la feuille de route de l’ENISA.

ECDSA est-il plus sûr que RSA ?

À taille de clé comparable en niveau de sécurité, par exemple RSA-3072 contre ECDSA P-256, les deux sont considérés comme sûrs par l’ANSSI et le NIST aujourd’hui. ECDSA est plus sensible aux erreurs d’implémentation, en particulier à un nonce faible ou réutilisé, comme l’a montré le piratage de la clé de signature de la PlayStation 3 en 2010. Cela ne rend pas ECDSA moins sûr sur le papier, mais cela exige des bibliothèques cryptographiques éprouvées plutôt qu’une implémentation maison.

Quelle taille de clé RSA faut-il utiliser en 2026 ?

L’ANSSI recommande un module RSA d’au moins 2048 bits pour un usage limité avant 2030, et d’au moins 3072 bits pour tout usage prévu au-delà de 2030, selon son guide ANSSI-PG-083 de mars 2026.

Quelle est la différence entre ECDSA et Ed25519 ?

Les deux reposent sur les courbes elliptiques, mais Ed25519 utilise une courbe différente (Curve25519) et un schéma de signature (EdDSA) plus récent, conçu pour éviter certains pièges d’implémentation d’ECDSA liés au nonce. Ed25519 est notamment devenu le type de clé par défaut d’OpenSSH. Pour une comparaison dédiée, consultez notre article ECDSA et Ed25519 en Node.js.

Un certificat ECDSA coûte-t-il plus cher qu’un certificat RSA ?

Non. Chez SSL.com comme chez la plupart des autorités de certification, RSA et ECC sont proposés au même prix, du certificat DV à 36,75 $ par an jusqu’au certificat EV à 239,50 $ par an. Let’s Encrypt propose les deux gratuitement.

Faut-il déjà migrer vers la cryptographie post-quantique ?

Pas dans l’urgence pour la majorité des usages, mais l’ANSSI recommande une hybridation dès 2025 pour toute donnée dont la confidentialité doit durer plus de dix ans. Notre guide sur la cryptographie post-quantique en Node.js détaille la mise en œuvre pratique.

Quels navigateurs et systèmes supportent ECDSA ?

Tous les navigateurs modernes (Chrome, Firefox, Safari, Edge) et la quasi-totalité des systèmes d’exploitation en support actif gèrent ECDSA nativement, tout comme la plupart des bibliothèques TLS côté serveur (OpenSSL, BoringSSL, LibreSSL). Seuls des clients très anciens, hors support depuis plusieurs années comme Windows XP ou les anciennes versions d’Android, posent encore un problème réel de compatibilité.

Peut-on utiliser RSA et ECDSA en même temps sur un même serveur ?

Oui, et c’est même la pratique recommandée pendant une migration. Nginx, Apache et Cloudflare supportent tous une configuration à double certificat, où le serveur présente automatiquement le certificat ECDSA aux clients compatibles et bascule vers RSA pour les autres. Cette approche évite de choisir entre performance et compatibilité : elle offre les deux en même temps, au prix d’une gestion de deux certificats au lieu d’un seul.