Discussion :

[Mathis Lucas]

Signal dévoile un protocole de chiffrement post-quantique conçu pour garantir la confidentialité persistante des échanges et la sécurité post-compromission
sans altérer les performances de l'application

Signal anticipe la menace quantique et renforce sa sécurité avec un nouveau protocole de chiffrement post-quantique. L'application lance Sparse Post-Quantum Ratchet (SPQR), un mécanisme avancé qui mettra continuellement à jour les clés de chiffrement utilisées dans les conversations et supprimera les anciennes. Ce nouveau composant garantit la confidentialité persistante et la sécurité post-compromission, assurant que même en cas de compromission ou de vol de clé, les futurs messages échangés entre les parties resteront sécurisés. L'ordinateur quantique pourrait briser les algorithmes de chiffrement classiques, rendant nos secrets électroniques vulnérables.

« Nous sommes ravis d'annoncer une avancée significative en matière de sécurité du protocole Signal : l'introduction du Sparse Post Quantum Ratchet (SPQR). Ce nouveau cliquet renforce la résilience du protocole Signal face aux futures menaces liées à l'informatique quantique, tout en conservant nos garanties de sécurité existantes en matière de confidentialité persistante et de sécurité post-compromission », a écrit l'équipe dans son annonce.

Signal est une application multiplateforme de messagerie chiffrée de bout en bout. SPQR apporte une sécurité post-quantique à des millions d'utilisateurs de Signal. La combinaison du SPQR et de l'algorithme Double Ratchet (double cliquet) existant offre une sécurité post-quantique renforcée tout en conservant toutes les propriétés de sécurité existantes de Signal et en restant très efficace en termes de bande passante.

« Il s'agit apparemment d'une amélioration solide et réfléchie du protocole Signal existant. Signal a procédé à une optimisation intéressante en arrière-plan afin de minimiser l'impact sur les performances du réseau de l'ajout de la fonctionnalité post-quantique », a déclaré Brian LaMacchia, ingénieur en cryptographie qui a supervisé la transition post-quantique de Microsoft de 2015 à 2022 et qui travaille désormais chez Farcaster Consulting Group.

À l'heure actuelle, environ la moitié des connexions TLS établies au sein du réseau Cloudflare et seulement 18 % des entreprises du Fortune 500 ont des réseaux protégés contre les attaques informatiques quantiques, ce qui signifie que très peu d'organisations sont prêtes. Ce fort taux d'impréparation est dû au coût et à l'absence de date butoir claire pour l'arrivée des ordinateurs quantiques. En attendant, Signal travaille à sécuriser davantage son application.

Un protocole de chiffrement hybride et résistant aux quantas

Le nouveau protocole de chiffrement post-quantique SPQR ajoute des protections basées sur ML-KEM-768, une implémentation de l'algorithme CRYSTALS-Kyber qui a été sélectionnée en 2022 et officialisée l'année dernière par le National Institute of Standards and Technology (NIST) des États-Unis. ML-KEM est l'abréviation de « Module-Lattice-Based Key-Encapsulation Mechanism », mais la plupart du temps, les cryptographes l'appellent simplement KEM.

À l'instar du protocole Diffie-Hellman à courbe elliptique (ECDH), KEM est un mécanisme d'encapsulation de clés. KEM permet à deux parties qui ne se sont jamais rencontrées de s'entendre en toute sécurité sur un ou plusieurs secrets partagés en présence d'un adversaire qui surveille leur connexion.

Les algorithmes RSA, ECDH et autres algorithmes d'encapsulation sont utilisé depuis longtemps pour négocier des clés symétriques (presque toujours des clés AES) dans des protocoles tels que TLS, SSH et IKE. Contrairement à ECDH et RSA, KEM est plus récent et résistant aux quantas.

Signal utilise CRYSTALS-Kyber (un KEM post-quantique) parallèlement à une implémentation du protocole Diffie-Hellman à courbe elliptique depuis 2023 afin de se protéger contre les attaques quantiques qui menacent de briser le chiffrement actuel des informations électroniques. SPQR vient s'ajouter au système « double cliquet » existant, formant ce que Signal appelle un « triple cliquet » (Triple Ratchet), qui formule une « clé mixte » hyper sécurisée.

Tout comme un cliquet traditionnel permet à un engrenage de tourner dans un sens, mais pas dans l'autre, les cliquets Signal permettent aux parties à la conversation de créer de nouvelles clés basées sur une combinaison de secrets précédents et nouvellement convenus. Les cliquets fonctionnent dans un seul sens, celui de l'envoi et de la réception des messages futurs. Même si un adversaire compromet un secret nouvellement créé, les messages chiffrés à l'aide d'anciens secrets ne peuvent pas être déchiffrés.

Les difficultés techniques rencontrées par l'équipe Signal

Comme indiqué précédemment, le protocole Signal a subi sa première refonte post-quantique en 2023. Cette mise à jour a ajouté PQXDH, une implémentation spécifique à Signal qui combine les accords de clés des courbes elliptiques utilisées dans X3DH (plus précisément X25519) et le KEM quantique sécurisé, dans la poignée de main initiale du protocole. (Par la suite, X3DH a ensuite été mis au rancart en tant qu'implémentation autonome.)

L'équipe a fait face à plusieurs défis techniques. Les clés à courbe elliptique générées dans l'implémentation X25519 ont une longueur d'environ 32 octets, ce qui est suffisamment petit pour être ajouté à chaque message sans alourdir les bandes passantes ou les ressources informatiques déjà limitées.

En revanche, une clé ML-KEM-768 fait 1 000 octets. De plus, selon l'annonce de l'équipe Signal, son implémentation nécessite l'envoi à la fois d'une clé de chiffrement et d'un texte chiffré, ce qui porte la taille totale à 2 272 octets. C’est donc 71 fois plus gros, ce qui signifie que les échanges chiffrés vont consommer encore plus de bande passante. Pour gérer cette augmentation, les développeurs de Signal ont envisagé différentes options.

Les pistes explorées par les développeurs de Signal

L'une des solutions proposées consistait à envoyer la clé KEM de 2 272 octets moins souvent, par exemple tous les 50 messages ou une fois par semaine, plutôt qu'à chaque message. Mais cette idée a été rejetée, car elle ne fonctionne pas bien dans les environnements de messagerie asynchrones ou conflictuels. Elle soulève également des risques en matière de sécurité. Graeme Connell et Rolfe Schmidt, développeurs du protocole Signal, ont expliqué :

Prenons le cas suivant : « envoyer une clé si vous n'en avez pas envoyé depuis une semaine ». Si Bob est hors ligne depuis deux semaines, que fait Alice lorsqu'elle veut envoyer un message ? Que se passe-t-il si nous pouvons perdre des messages et que nous perdons celui sur cinquante qui contient une nouvelle clé ? Ou bien, que se passe-t-il s'il y a un attaquant qui veut nous empêcher de générer de nouveaux secrets et qui peut rechercher les messages qui sont [beaucoup] plus volumineux que les autres et les supprimer, ne laissant passer que les messages sans clé ?

Une autre option envisagée par les ingénieurs de Signal consistait à diviser la clé de 2 272 octets en morceaux plus petits, par exemple 71 morceaux de 32 octets chacun. Diviser la clé KEM en morceaux plus petits et en mettre un dans chaque message semble être une approche viable à première vue, mais là encore, l'environnement asynchrone de la messagerie rendait cette solution inapplicable. Par exemple, que se passe-t-il lorsqu'une perte de données entraîne la suppression d'un des morceaux ?

Le protocole pourrait gérer ce scénario en renvoyant simplement les morceaux après avoir envoyé les 71 précédents. Mais alors, les ingénieurs ont souligné qu'un adversaire surveillant le trafic pourrait simplement faire en sorte que le paquet 3 soit supprimé à chaque fois, empêchant Alice et Bob de terminer l'échange de clés. Les développeurs de Signal ont finalement opté pour une solution utilisant cette approche à plusieurs morceaux.

Relever les défis liés à l'asynchronisme

Pour relever les défis liés à l'asynchronisme, les développeurs se sont tournés vers les « codes d'effacement », une méthode qui consiste à diviser les données volumineuses en petits morceaux afin que l'original puisse être reconstitué à partir de n'importe quel sous-ensemble de morceaux suffisamment grand.

Charlie Jacomme, chercheur à l'INRIA Nancy au sein de l'équipe Pesto, spécialisé dans la vérification formelle et la messagerie sécurisée, explique que cette conception tient compte de la perte de paquets en intégrant une redondance dans les fragments. Au lieu d'exiger que tous les x fragments soient reçus pour reconstruire la clé, le modèle ne nécessite que la réception de x-y fragments, où y est le nombre acceptable de paquets perdus.

Tant que ce seuil est atteint, la nouvelle clé peut être établie même en cas de perte de paquets. L'autre partie de la conception consistait à diviser les calculs KEM en étapes plus petites. Ces calculs KEM sont distincts du matériel de clé KEM. Comme l'explique Charlie Jacomme :

En substance, une petite partie de la clé publique suffit pour commencer à calculer et à envoyer une plus grande partie du texte chiffré, ce qui permet d'envoyer rapidement en parallèle le reste de la clé publique et le début du texte chiffré. Les calculs finaux sont identiques à la norme, mais certains éléments ont été parallélisés.

Tout cela joue en fait un rôle dans les garanties de sécurité finales, car en optimisant le fait que les calculs KEM sont effectués plus rapidement, vous introduisez plus fréquemment de nouveaux secrets dans votre dérivation de clé.

Si cette conception résolvait le problème de la messagerie asynchrone, elle créait toutefois une nouvelle complication : ce nouveau mécanisme quantique sécurisé avançait si rapidement qu'il était impossible de le synchroniser avec le mécanisme Diffie-Hellman. Finalement, les architectes ont opté pour une solution créative. Plutôt que d'ajouter le KEM au double cliquet existant, ils l'ont laissé plus ou moins tel quel. Ils ont ensuite utilisé le nouveau cliquet quantique sécurisé pour mettre en œuvre un système de messagerie sécurisé parallèle.

Désormais, lorsque le protocole de Signal chiffre un message, il tire ses clés de chiffrement à la fois du double cliquet classique et du nouveau cliquet. Il mélange ensuite les deux clés (à l'aide d'une fonction de dérivation de clé cryptographique) pour obtenir une nouvelle clé de chiffrement qui offre toute la sécurité du double cliquet classique, mais qui bénéficie désormais également d'une sécurité quantique. Les ingénieurs de Signal ont donné à ce troisième cliquet le nom officiel de Sparse Post Quantum Ratchet (SPQR).

Le déploiement du chiffrement post-quantique sera progressif

Le nouveau protocole de chiffrement SPQR a été développé en collaboration avec PQShield, AIST et l'université de New York. Les développeurs ont présenté le découpage en morceaux basé sur un code d'effacement et la conception de haut niveau du Triple Ratchet lors de la conférence Eurocrypt 2025. La conception a également été formellement vérifiée à l'aide de ProVerif, et la robustesse de l'implémentation Rust a été testée à l'aide de l'outil hax.

Une vérification continue sera désormais appliquée à toutes les versions futures, garantissant que les preuves sont reproduites à chaque modification du code. L'équipe Signal a annoncé que le protocole SPQR sera déployé progressivement au cours des prochaines semaines ou des prochains mois et que les utilisateurs n'auront aucune mesure à prendre pour que la mise à niveau s'applique, hormis la mise à jour de leurs clients vers la dernière version.

Le nouveau système sera rétrocompatible dans le sens où, lorsqu'un client compatible SPQR communique avec une personne qui ne prend pas encore en charge cette technologie, le modèle de sécurité sera rétrogradé. Une fois que SPQR sera disponible pour tous les clients, Signal l'appliquera à toutes les sessions.

Les chercheurs externes saluent ce travail. « Si les messages chiffrés normaux que nous utilisons sont des chats, alors les textes chiffrés post-quantiques sont des éléphants. Le problème ici est donc de faire passer un éléphant dans un tunnel conçu pour les chats. C'est une prouesse technique incroyable. Mais cela me fait aussi regretter que nous ayons à nous occuper d'éléphants », a déclaré Matt Green, expert en cryptographie à l'université Johns Hopkins.

Source : Signal

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du nouveau protocole de chiffrement post-quantique de Signal ?

Voir aussi

Qu'est-ce que le chiffrement post-quantique ? L'ordinateur quantique pourrait briser les algorithmes de chiffrement, rendant nos secrets électroniques vulnérables

GitHub déploie un nouvel algorithme hybride d'échange de clés SSH sécurisé post-quantique afin de renforcer la sécurité de l'accès aux données Git, offrant une protection renforcée aux utilisateurs SSH

BlackRock avertit que l'informatique quantique pourrait rendre le code source du bitcoin « défectueux ou inefficace », suggérant que la cryptomonnaie doit se préparer à un monde post-quantique

[Anthony]

« Il n'y a pas vraiment d'autre choix » : la présidente de Signal explique pourquoi la messagerie chiffrée s'appuie sur Amazon Web Services, après la récente panne majeure d'AWS qui a également touché Signal

La présidente de Signal, Meredith Whittaker, a répondu aux critiques concernant la dépendance de la messagerie chiffrée à Amazon Web Services (AWS), à la suite d'une panne importante d'AWS qui a affecté plusieurs services, dont Signal. Meredith Whittaker a souligné le problème plus général de la concentration des infrastructures cloud, notant que l'absence d'alternatives viables oblige des entreprises comme Signal à dépendre d'une poignée de fournisseurs dominants. L'incident d'AWS a mis en évidence les vulnérabilités inhérentes à l'écosystème technologique actuel, dans lequel même les entreprises axées sur la confidentialité sont obligées de dépendre des géants technologiques qu'elles tentent de contourner.

Signal est un service de messagerie chiffrée open source qui permet d'échanger des messages instantanés (textes, notes vocales, images, vidéos et autres fichiers), ainsi que de passer des appels vocaux et vidéo. La fonction de messagerie instantanée a été développée par l'entreprise américaine Signal Messenger LLC et est financée par la Signal Foundation, une organisation à but non lucratif. En octobre 2025, Signal a dévoilé un protocole de chiffrement post-quantique conçu pour garantir la confidentialité persistante des échanges et assurer la sécurité post-compromission, le tout sans altérer les performances de l'application. Nommé Sparse Post-Quantum Ratchet (SPQR), ce mécanisme garantit ainsi que les futurs messages échangés entre les parties resteront sécurisés, même en cas de compromission ou de vol de clé.

Amazon Web Services, Inc. (AWS) est une filiale d'Amazon qui fournit des plateformes de cloud computing à la demande et des API aux particuliers, aux entreprises et aux gouvernements, sur la base d'une facturation à l'utilisation. Amazon commercialise AWS auprès des abonnés comme un moyen d'obtenir une capacité de calcul à grande échelle plus rapidement et à moindre coût que la construction d'une ferme de serveurs physiques. Au premier trimestre 2023, AWS détenait 31 % des parts de marché de l'infrastructure cloud, tandis que ses deux principaux concurrents, Microsoft Azure et Google Cloud, en détenaient respectivement 25 % et 11 %, selon Synergy Research Group.

Le lundi 20 octobre 2025, Amazon a signalé une panne massive du service de cloud AWS, mettant hors service plusieurs sites web importants et certaines des applications les plus populaires au monde, comme Snapchat, Reddit, Alexa, Fortnite, Roblox ou encore Coinbase. Cette panne a perturbé une grande partie d'Internet et les activités commerciales à l'échelle mondiale.

Suite à cet incident, la présidente de Signal, Meredith Whittaker, a répondu aux critiques qui remettaient en question la dépendance de la messagerie chiffrée à Amazon Web Services, en affirmant que la concentration des infrastructures cloud ne laissait aucune alternative réaliste aux entreprises.

Meredith Whittaker a fait un constat réaliste sur l'infrastructure cloud que de nombreux utilisateurs de technologies ne voulaient pas entendre. Après qu'Elon Musk et d'autres aient critiqué la dépendance de Signal vis-à-vis d'Amazon Web Services à la suite de la panne de la semaine dernière, Whittaker s'est exprimée sur Bluesky avec une évaluation sans détour : il n'existe tout simplement pas d'alternatives viables.

« Le problème ici n'est pas que Signal ait « choisi » de fonctionner sur AWS », a écrit Meredith Whittaker dans un fil de discussion détaillé. « Le problème est la concentration du pouvoir dans le domaine des infrastructures, qui signifie qu'il n'y a pas vraiment d'autre choix : toute la pile, d'un point de vue pratique, appartient à 3 ou 4 acteurs. »

Cette révélation a pris de court de nombreux utilisateurs de Signal, mais Meredith Whittaker affirme que cette surprise fait partie du problème. Le nombre de personnes qui ne savaient pas que Signal utilisait AWS est « préoccupant », selon elle, car cela montre à quel point la concentration des infrastructures cloud est méconnue. Si vos messages chiffrés dépendent des mêmes serveurs que ceux qui alimentent les appareils Alexa et Fortnite, ce n'est pas la faute de Signal, mais le résultat inévitable de décennies de consolidation des infrastructures.

La réalité technique corrobore l'argument de Meredith Whittaker. L'exploitation d'une plateforme qui gère des millions d'appels audio et vidéo simultanés nécessite ce qu'elle appelle « un réseau préconstruit de calcul, de stockage et de présence en périphérie, qui couvre toute la planète et qui nécessite une maintenance constante, une consommation électrique importante et une attention et une surveillance persistantes ». Construire cela à partir de zéro coûterait des milliards, ce qui le rendrait inaccessible pour la plupart des entreprises.

Cela laisse à Signal trois options réalistes : Amazon Web Services, Microsoft Azure ou Google Cloud. Le choix entre ces géants technologiques n'en est pas vraiment un lorsque l'on a besoin d'une couverture mondiale et d'une latence inférieure à la seconde pour des communications en temps réel.

Meredith Whittaker a souligné que Signal ne fonctionne que « partiellement » sur AWS et utilise un chiffrement de bout en bout pour garantir que ni Signal ni Amazon ne puissent accéder aux conversations des utilisateurs. Mais cette protection technique ne résout pas le problème plus large de la dépendance à l'infrastructure, qui est devenu douloureusement évident lorsque AWS est tombé en panne.

La panne n'était pas seulement un problème pour Signal. Elle a également affecté les commandes mobiles chez Starbucks, les téléchargements sur Epic Games Store, les sonnettes Ring, les fonctionnalités Snapchat et même les lits intelligents, laissant les utilisateurs en proie à une chaleur excessive. Lorsqu'un seul fournisseur de services cloud peut perturber tout, des commandes de café à la qualité du sommeil, le problème de concentration des infrastructures dépasse largement le cadre des applications de messagerie.

Microsoft et Google sont confrontés aux mêmes problèmes de dépendance avec leurs propres services. Teams, Office 365, Gmail et YouTube dépendent tous de leurs plateformes cloud respectives. La différence est que ces entreprises possèdent leur propre infrastructure, un luxe que les petites entreprises comme Signal ne peuvent pas se permettre.

Les chiffres sont éloquents. AWS a généré 90 milliards de dollars de chiffre d'affaires l'année dernière, tandis que Signal fonctionne comme une organisation à but non lucratif avec une fraction de ce budget. Même les start-ups bien financées ont du mal à justifier les dépenses d'investissement nécessaires pour mettre en place une infrastructure mondiale alors que les fournisseurs de cloud computing proposent ce service.

Meredith Whittaker considère cette panne comme une occasion potentielle d'« apprendre » les risques liés à la concentration des infrastructures. « Mon espoir, c'est que la panne d'AWS puisse être une occasion d'apprendre, où les risques liés à la concentration du système nerveux de notre monde entre les mains de quelques acteurs deviennent très clairs », a-t-elle écrit.

Le débat met en évidence une tension fondamentale dans la technologie moderne. Les utilisateurs veulent bénéficier des avantages d'une communication mondiale et instantanée sans accepter les compromis infrastructurels qui la rendent possible. Signal ne peut pas offrir à la fois une fiabilité comparable à celle de WhatsApp et une indépendance totale vis-à-vis des grandes plateformes technologiques.

La défense par Meredith Whittaker de la dépendance de Signal vis-à-vis d'AWS révèle une vérité dérangeante sur l'infrastructure Internet moderne. Alors que les utilisateurs exigent à la fois confidentialité et performances, les réalités économiques de l'informatique à l'échelle mondiale obligent même les entreprises qui accordent la priorité à la confidentialité à nouer des relations avec les mêmes géants technologiques qu'elles tentent de contourner.

La véritable question n'est pas de savoir si Signal devrait utiliser AWS, mais si trois entreprises devraient contrôler l'épine dorsale des communications mondiales. Tant qu'aucune alternative n'aura vu le jour, même les services les plus soucieux de la confidentialité resteront dépendants de l'oligopole des infrastructures auquel ils s'opposent philosophiquement.

Alors que la présidente de Signal affirme que la dépendance de l'application de messagerie envers AWS est inévitable, la récente panne du service cloud d'Amazon met en lumière la vulnérabilité d'une grande partie d'Internet face à la domination de quelques acteurs du cloud. Un seul point de défaillance, lié au dysfonctionnement d'un gestionnaire DNS dans une seule région du vaste réseau d'Amazon, a en effet déclenché la panne d'AWS, touchant des millions de personnes et paralysant une partie d'Internet pendant seize heures.

Cet incident a ravivé les inquiétudes des experts, qui estiment que la centralisation excessive du cloud laisse les entreprises et les utilisateurs « à la merci » d'un nombre trop restreint de fournisseurs. La panne du 20 octobre 2025 a plongé des dizaines de services en ligne dans le chaos, démontrant que l'économie numérique repose sur une infrastructure trop concentrée, où une seule erreur peut paralyser le réseau mondial. Pour beaucoup, cette situation confirme que la résilience d'Internet repose désormais sur trop peu d'acteurs.

Source : Meredith Whittaker, présidente de Signal

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous la position de la présidente de Signal cohérente et pertinente ?

Voir aussi :

La panne d'AWS a provoqué la surchauffe et le blocage en position verticale de lits « intelligents » à 2 000 dollars, dévoilant la fragilité du rêve connecté d'Eight Sleep

Les services cloud AWS d'Amazon rétablis après une panne d'une journée qui a touché plusieurs sites web importants : « Nous publierons un rapport détaillé sur cet incident », a déclaré la société

[ericb2]

Il est là le problème : " Alors que les utilisateurs exigent à la fois confidentialité et performances"

C'est simplement FAUX : les utilisateurs exigent bien la performance, mais ils n'ont même pas conscience de ce que signifie le mot "confidentialité". Si c'était le cas, personne n'utiliserait Whatsapp ni tout ce qui vient de chez Microsoft.

Mme Whitaker est brillante et toujours pertinente. C'est quelqu'un d'exceptionnel, et c'est une chance d'avoir une nana comme ça à la tête de Signal. Pourvu que ça dure.

[calvaire]

il existe pourtant des protocoles décentralisé...
une DHT pour la découverte réseaux et un système d’identité basé sur les clés publiques par exemple.

à la rigueur un serveur centrale pour:
- Trouver l’autre utilisateur.
- Passer à travers les pare-feux/NAT.
- Éventuellement relayer le flux si le P2P direct échoue


signal j'ai du l'utiliser 1 minutes max dans ma vie, premier lancement il me demande le numéro de téléphone...pourquoi faire ?
j'utilise Jami avec un compte ring qui est lui 100% décentralisé.

Signal pourrait évoluer dans ce sens, se passer du numéro de téléphone et utiliser un id de 30 caractère/qrcode par exemple (comme sur jami)
Proposer un fonctionnement avec Open DHT.
Ca pourrait grandement alléger leurs charge serveurs et aussi se passer de aws en cas de panne (avec un mode "dégradé").

Un exemple j'avais développé il y'a 15ans un jeu multijoueurs en p2p (sans serveur centrale), tous les joueurs exécutent la même simulation localement et chaque action est envoyée à tous les autres joueurs sous forme d’instruction, en fonction du nombre de joueurs (de 1 à 1000) il envoi par paquets de 10 aux plus proches et ces 10 autres envois aux 10 autres plus proches...etc.
Autre exemple notre datacenter à singapour, si il fallait le redémarrer en cas de scénario catastrophe, repose sur du bittorrent pour le boot pxe, y'a +2000 serveurs, ce serait impossible de charger 2000 fois une image, on en démarre une 50 aines, et ensuite la 50aines fait démarrer les 2000 autres nœuds.
Je pense que le p2p est en 2025 toujours largement sous exploités, il permet de gros gains aux entreprises en réduisant drastiquement les frais d’infra (qui repose sur les utilisateurs).

Je pense que la formation des dev est aussi mauvaise la dedans, les dev apprennent à coder en procédurale et en client-serveur.
les formations qui font découvrir le fonctionnelle et le p2p sont bien plus rare, ils sont peu a connaitre et maitriser ces paradigmes de programmation.

Dans un autre registre, pourquoi les maj se font encore majoritairement en mise à jour complète, les maj delta allègent énormément les infras réseaux. J'ai en têtes les jeux vidéos principalement, ou l'on me fera pas croire que pour un patch des devs ont modifié 50go de données...

[Fagus]

...

C'est la maladie de la surabondance. Les ressources sont surabondantes et ya Bibi qui paie à la fin donc tout le monde s'en fiche de l'optimisation.

Avant, au temps des modem RTC, il n'y avait que des mises à jour delta.

Je connais une boîte de formation, avec une audience de centaines de vidéos par an d'une heure pour un ordre de grandeur de 10 000 adhérents. Leurs vidéos font dans les 2Go chacune alors que c'est juste de la voix et des powerpoint à 90%. Bizarrement, quand je recompresse avec des optimisations "still image" et opus, on divise la taille couramment de 2 ordres de grandeurs (versus leur format HD à débit constant). Je l'ai signalé mais tout le monde s'en fiche. Il suffit de mettre plus d'infrastructure et de la faire payer et tant pis si malgré ça le réseau rame encore.

Windows ça a l'air pareil. Toutes les app. natives de windows 11 chargent avec un délai très perceptible sur des config énormes pour de la bureautique (ex, calc, viewer), alors que sur mon raspberry 5 bien réglé, le délai est imperceptible.

[calvaire]

Je connais une boîte de formation, avec une audience de centaines de vidéos par an d'une heure pour un ordre de grandeur de 10 000 adhérents. Leurs vidéos font dans les 2Go chacune alors que c'est juste de la voix et des powerpoint à 90%. Bizarrement, quand je recompresse avec des optimisations "still image" et opus, on divise la taille couramment de 2 ordres de grandeurs (versus leur format HD à débit constant). Je l'ai signalé mais tout le monde s'en fiche. Il suffit de mettre plus d'infrastructure et de la faire payer et tant pis si malgré ça le réseau rame encore.

et pourtant la video et l'un des rares domaines ou y'a de l'optimisation chez les gros.
Les géants comme youtube ont migré vers l'av1 et la résolution proposé part défaut est jamais du 4k.

ré-encoder les vidéos en av1 est pas compliqué. Bien vérifié avant quand même ce qui va lire les vidéos, si c'est des vielles machines embarqué sous windows xp, l'av1 n'est pas un bon plan, si c'est des étudiants/salariés avec des pc qui ont moins de 10ans, l'av1 en FHD marchera très bien.


Je suis toujours tres décu coté smartphone, y'a que google qui propose l'enregistrement de videos en av1, les autres sont encore au mieux sur de l'h.265.
le gain de place est pourtant bien la, quand je les reencode sur mon pc, je gagne 20% d'espace disque sur mes films face au h.265.