Les erreurs de données silencieuses, ou la corruption silencieuse des données (Silent Data Errors/Silent Data Corruption), révèlent un écart croissant entre la réussite d’une puce aux tests de fabrication traditionnels et sa capacité à produire des résultats corrects pendant toute sa durée d’exploitation. Un processeur peut réussir les tests ATPG, les tests de défauts de transition et de défauts bloqués, ainsi que les tests structurels à la vitesse de fonctionnement, puis exécuter incorrectement une opération de calcul sans enregistrer de défaillance manifeste, avant que le résultat corrompu ne soit transmis à une application ou à une tâche d’entraînement d’intelligence artificielle.
Cette analyse s’appuie sur un article publié par Semiconductor Engineering le 10 septembre 2026, qui rassemble des avis et des résultats d’Advantest, Siemens EDA, NXP, Synopsys, Intel, Meta, Google et proteanTecs. Il ne s’agit pas du lancement d’un produit précis, mais d’une évolution dans la manière de définir la qualité d’un processeur, d’évaluer la couverture de ses tests et de le gérer après son arrivée dans le centre de données.
Un problème rare à l’échelle de la puce, étendu à l’échelle de la flotte
Les erreurs de données silencieuses semblent rares lorsqu’elles sont mesurées sur un appareil isolé, mais elles deviennent fréquentes et coûteuses lorsque des millions de processeurs fonctionnent avec des taux d’utilisation élevés. Des analyses préliminaires de Google et de Meta indiquent que ces erreurs peuvent toucher un serveur sur mille, soit un niveau compris entre 100 et 1 000 pièces défectueuses par million. Même un taux de 10 FIT, soit une défaillance par milliard d’heures de fonctionnement, peut signifier qu’une erreur survient environ tous les quatre jours lorsque 10 millions d’appareils sont déployés.
Le danger réside dans le fait que l’erreur peut se manifester sous la forme d’un résultat numérique incorrect ou d’une valeur indéfinie, puis entraîner la corruption de bases de données, un comportement inattendu d’un modèle d’intelligence artificielle ou des résultats analytiques contradictoires. Comme le processeur lui-même peut ne pas envoyer de signal d’erreur, la défaillance peut ne pas être détectée avant l’apparition d’un résultat illogique à la fin d’une longue tâche.
Pourquoi les tests traditionnels échouent-ils ?
Les erreurs silencieuses sont liées à des défauts marginaux tels que des interconnexions métalliques à résistance élevée, des défauts de pont faibles, des variations de synchronisation et de tension, ainsi qu’aux effets du vieillissement, des radiations, de la température et de la charge. Leur probabilité augmente avec les nœuds de fabrication avancés, où les marges se réduisent et où les interconnexions deviennent plus petites et plus résistives. Les boîtiers reposant sur des chiplets accroissent également la complexité des chemins de vérification.
L’industrie estime qu’environ 80 % des erreurs d’exécution corrompues sont liées à des défauts qui échappent aux tests au temps zéro, tandis que les 20 % restants apparaissent de manière intermittente ou résultent du vieillissement. Toutefois, tester toutes les combinaisons possibles de tension, de fréquence, de température, d’âge et de type de charge n’est pas pratique. De plus, relier une défaillance apparue au niveau du système à un motif de défaut précis lors du test de la puce peut prendre des semaines et nécessite la coopération des équipes de conception, de test, d’analyse des défaillances et d’intégration des systèmes.
Siemens EDA souligne que le recours à la commutation d’une seule entrée lors du test des défauts de retard peut ne pas reproduire le fonctionnement réel, car la commutation de plusieurs entrées peut produire des retards plus importants. Les tests doivent donc cibler plusieurs combinaisons de tension, de température et de fréquence, au lieu de se limiter à des modèles de défauts structurels qui ne couvrent pas toutes les conditions d’utilisation.
Des tests plus approfondis, de l’usine au centre de données
Ce problème redéfinit la notion de couverture des tests. Au lieu de comptabiliser la proportion de défauts de fabrication connus que le test peut détecter, la couverture devient également liée à la probabilité de découvrir une réponse de calcul incorrecte lors d’un fonctionnement réel et avec une charge effective. C’est pourquoi les entreprises s’orientent vers des tests fonctionnels au niveau du système, des tests adaptés à la charge et des tests en conditions de tâche, en plus d’améliorer la conception des tests intégrés et la surveillance des marges à l’intérieur de la puce.
L’expérience d’Intel illustre l’ampleur du défi. Après avoir testé 1,2 million de processeurs sur cinq générations de processeurs Intel Xeon, l’entreprise a eu besoin de plus de 1 000 tests fonctionnels dans la suite DCDiag et de 5 000 tests de contrainte synthétiques pour détecter les défauts d’erreurs silencieuses. Les tests n’étaient pas répartis uniformément entre les défauts : environ 50 % des pièces défectueuses pouvaient être détectées avec seulement 5 % des tests, tandis que la détection de 90 % des erreurs nécessitait plus de la moitié des 1 000 tests. Les résultats ont également montré que plus de 70 % des défauts n’étaient détectés que par un seul test et que la recette de test efficace pour une génération de produits ne pouvait pas être directement transposée à la génération suivante.
Qu’est-ce qui change concrètement dans les flottes ?
La réponse ne s’arrête pas à la sortie de l’usine. Les exploitants de centres de données utilisent plusieurs niveaux de contrôles logiciels et de tests sur le terrain pour isoler les serveurs ou les cœurs qui présentent un comportement anormal. Chez Meta, le programme Fleetscanner retire le serveur du service et l’exécute sur des tests de calcul aux résultats connus, tandis que le programme Ripple exécute de courts motifs pendant le fonctionnement normal. Hardware Sentinel analyse les exceptions des applications et le comportement du système sans réserver de charges de test. Meta a indiqué qu’il avait amélioré la détection de 40 % par rapport aux méthodes fondées sur les tests, à travers différentes architectures, applications et centres de données.
Google utilise un ensemble de moyens de protection, notamment la vérification de bout en bout des ensembles de tests, les calculs redondants et leur comparaison, les contrôles d’invariants et les assertions, la vérification des données pendant leur transfert et la vérification périodique des données stockées. La mesure des applications, comme la méthode Spanner, peut également détecter la corruption et retirer du parc les appareils suspects, tandis que les méthodes de contrôle sont ajustées lors du retour des appareils afin d’identifier les cœurs exposés au problème avant son aggravation.
Du test avant expédition à la gestion du cycle de vie du silicium
Ces tendances encouragent une surveillance continue des marges de synchronisation, de tension, de température et de dégradation, ainsi que l’utilisation de l’analyse des séries temporelles et de l’apprentissage automatique pour détecter les écarts avant qu’ils ne se transforment en erreur silencieuse. Les mesures paramétriques et les modèles d’apprentissage automatique peuvent contribuer à isoler les appareils qui s’écartent de leur profil attendu, tandis que la diversification des tests d’instructions, l’exécution redondante et la comparaison entre les cœurs peuvent accroître les chances de détection.
Cette approche n’élimine toutefois pas les limites. Aucune méthode unique ne permet de détecter tous les mécanismes d’erreur, les résultats des tests ne se transfèrent pas automatiquement d’une conception à une autre, et le diagnostic de la cause profonde reste difficile lorsque l’effet apparaît dans l’application, loin du défaut matériel. L’analyse indique également que le partage des données de défaillance entre les fabricants, les fournisseurs d’outils de test, les exploitants de centres de données et les universités demeure limité en raison de considérations commerciales et juridiques. Le véritable changement ne consiste donc pas à ajouter un test isolé, mais à construire une chaîne de visibilité qui s’étend de la fabrication à l’exploitation, tout en reconnaissant que la qualité d’un processeur n’est pas entièrement déterminée au moment de son expédition.